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ABSTRACT 



This thesis outlines the theoretical underpinnings used 
for the software designed to meet Detailed Technical 
Objectives 700-6 and 700-7 for the Space Shuttle Discovery- 
mission STS-51 . The primary goal was to compare state vector 
information produced by an on board GPS receiver and 
Discovery's computers, and provide real time display of the 
results. Because state vector information for the ORFEUS/SPAS 
payload was also available, relative position and rendezvous 
information between Discovery and ORFEUS/SPAS was made 
possible. Analysis of the various state vectors was used to 
produce a graphical display, in an operationally meaningful 
format, to the flight crew of Discovery. 
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I . INTRODUCTION 



On 12 September 1993, the Space Shuttle Discovery launched 
for STS-51. One of the experiments performed during this 
flight was entitled DTO (Detailed Technical Objective) 700. 
DTO 700 was actually a compilation of experiments related to 
the use of portable computers for on orbit navigation aids. 
Portions of the software for DTO 700 were produced by a design 
team from the Naval Postgraduate School (NPS) . 

The primary responsibility of the NPS software was to 
perform rudimentary state vector comparison with information 
obtained from two separate sources. However, in the 
development stage of the project, it became apparent that much 
more than basic state vector comparison was possible. 
Additional state vector sources and orbiter attitude 
information became available, which provided the means of 
presenting meaningful operational information to the crew of 
STS-51. This thesis presents the theoretical basis for 
software developed by the NPS team which processed the various 
sources of state vector and attitude information into formats 
that were meaningful to Discovery's crew. 

The secondary payload for STS-51 was the Shuttle Pallet 
Satellite (SPAS) carrying the ORFEUS payload. Since SPAS was 
designed to operate in proximity with Discovery, it produced 
a data stream that was continually data linked to Discovery 
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and available to the NPS software via Discovery's main 
computers. This data stream contained two separate sources of 
state vector information for SPAS. The first was produced by 
a GPS receiver, while the second was the output of orbit 
propagation software resident in computers located on the 
satellite. A second GPS receiver (a portable Trimble 
Navigation TANS GPS receiver) was on board Discovery providing 
orbiter state vector information. Discovery's own computers 
also produced state vectors for the orbiter and SPAS as well 
as orbiter attitude information. These sources of information 
provided the inputs for the derivations presented. 

The primary responsibility of the NPS software was to 
compare the orbiter state vector information produced by the 
portable TANS GPS receiver, to that produced by Discovery's 
computers. The GPS information was ported directly to the GRID 
1530 386/10 laptop computer being used for the comparison. The 
orbiter generated state vector information was read from 
information being downlinked to ground controllers. Tapping 
into this data stream provided the means of reading SPAS state 
vector information, as well as orbiter attitude information. 
The additional information provided by SPAS allowed the 
original scope of DTO 700 to be expanded to include displaying 
information with operational significance. 

The executable program that flew aboard STS-51 contains 
three families of routines that provide information to the 
flight crew. The first group, called the sawtooth plots, 
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display magnitude differences between various parts of the 
input state vectors. This family of plots were designed to 
satisfy the primary responsibility of the NPS software. 

The second family, called the RBAR/VBAR plots, are 
designed to show relative motion between spacecraft operating 
in proximity. This type of plot is used by the astronauts in 
planning their mission. The target spacecraft is placed in the 
center of a local vertical/circular coordinate system, while 
the pursuing spacecraft's position is displayed graphically by 
an altitude and downrange difference. The out of plane error 
is shown in an alphanumeric format to complete the three 
dimensional information. It is important to note that this is 
not a rectilinear coordinate system, however information 
displayed with this method provides a very intuitive feel of 
relative orbital motion. 

The third family, called the Pitch/Yaw plots, was created 
as a means of providing information to the flight crew to 
assist in locating SPAS. This is accomplished by creating a 
vector to SPAS and then transforming it into a Shuttle based 
coordinate system. The information is finally displayed in 
terms of pitch and yaw angles. 

Due to the proximity operations with SPAS, this thesis 
also addresses rendezvous solutions for spacecraft in similar 
orbits. In testing the software that was to fly, the need to 
maneuver the simulated Shuttle orbiter arose. Short routines 
used to apply velocity changes to the Shuttle's state vector 
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were created. These, however, were not designed to provide 
the velocity changes to apply for a given maneuver. The 
linearized relative equations of motion as presented in 
Reference 1 were solved in order to determine the velocity 
changes needed to initiate and terminate a rendezvous. The 
solutions to these equations are derivatives with respect to 
a non-inertial frame, requiring great care in transforming to 
the inertial frame. Only the initial velocity change solution 
has been incorporated in the NPS software, and this was 
disabled in the primary executable that flew aboard STS-51. 

The rendezvous information that was incorporated in the 
executable that flew aboard STS-51 did not in itself produce 
a solution for rendezvous, but rather produced a prediction of 
relative position based on user input velocity changes in the 
Shuttle's coordinate system. The prediction was based on 
classical elements and the "f" and "g" functions, which do not 
account for accelerations other than those associated with the 
classic two body problem. However, for similar orbits, 
perturbing accelerations have similar effects and thus have 
minimal effect on relative motion. 

The mathematics and physics of this thesis are not 
difficult to follow. The significance of this work lies in the 
applicability of commonly understood principles for a very 
relevant purpose. Flying an aircraft is very intuitive, 
however, flying a spacecraft requires knowledge of orbital 
mechanics and dynamics. 
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The software that flew aboard STS-51 automated many of the 
principles of these disciplines, and gave the crew of STS-51 
a graphical presentation of their current situation, as well 
as their history, and a means of predicting future motion. 
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II. STATE VECTOR COMPARISON 



The primary purpose of DTO 700 was to provide on orbit 
state vector comparison between orbiter generated state 
vectors and state vectors generated by the TANS portable GPS 
receiver. A state vector is composed of two cartesian vectors 
and a time element. The vectors represent the position and 
velocity of the prescribed spacecraft and are expressed in an 
inertial coordinate system known as M50. Throughout this 
treatment, the assumption is that state vectors being compared 
have the same time stamp. In reality, this rarely occurs. To 
account for unmatched times of state vectors, a Cowell 
integrator is used to propagate one of the state vectors until 
the state vectors are concurrent . 

A. ORBITER STATE VECTOR GENERATION 

The motivation for the state vector comparison is the 
belief that orbiter derived state vectors can accrue errors 
relatively quickly. The orbiter produces state vectors with on 
board computers by using orbit propagation software known as 
the "Super G" . Periodically, ground controllers uplink an 
updated state vector to the orbiter derived from information 
collected by ground tracking stations. This state vector 
serves as the new initial condition for the Super G 
propagator, which provides a continuous stream data based on 
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the latest initial conditions. As with any numerical 
propagator, error is expected to accrue. Unfortunately, due to 
computational hardware limitations, the Super G is essentially 
a low fidelity propagator, which results in the possibility of 
increasingly large state vector errors during periods between 
state vector updates. 

B. TANS STATE VECTOR GENERATION 

The TANS portable GPS receiver generated the state vectors 
against which the Super G derived state vectors were compared. 
A GPS receiver can produce a state vector based on the 
information received from any four GPS satellites at a given 
instant. Given a period of favorable geometry with respect to 
GPS satellites, the TANS receiver produces a continuous stream 
of state vectors which have a bounded error. Initial data 
[Ref. 2] indicates accuracies within 100 meters in position 
and on the order of meters per second in velocity. 

In addressing the requirements of DTO 700, the first 
responsibility of software created by the Naval Postgraduate 
School was to use these GPS derived state vectors, 
characterized by bounded error, to demonstrate the rate at 
which state vectors produced by the Super G degrade, and begin 
to validate the use of GPS as an on orbit navigation aid. 
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C . SAWTOOTH PLOTS 



These plots derived their name from the expected form of 
their output data. Assuming the uplinked orbiter state 
vector's accuracy, it was expected that as the Super G 
propagated away from 'truth', the difference of the orbiter 
and TANS state vectors should become more pronounced, while at 
the instant a new state vector was uplinked, the difference 
should be minimized. To display this, a very simple algorithm 
comparing the difference vectors, in position and velocity, is 
presented. 

Let ? T and v T represent the position and velocity vectors 
produced by the TANS receiver, while ? 0 and v Q represent the 
position and velocity vectors produced by the orbiter. The 
difference vectors (r d and v d ) are given by 



v. 




( 2 . 1 ) 



The magnitudes of these difference vectors, given by 

r d = II rj 

( 2 . 2 ) 

v d = l?dl 

are plotted against time to show the relative behavior of the 
two sources . 

Figures 2.1 and 2.2 show the display screens of r d and v d 
plots that were produced in simulation. For this simulation, 
a corrected uplinked state vector is created by matching the 
orbiter state vector with the simulated TANS state vector. The 
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Figure 2 . 1 Sawtooth Plot of Position vs Time 
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Figure 2.2 Sawtooth Plot of Velocity vs Time 
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drift between state vectors is achieved by using a lower 
fidelity propagator for the orbiter state vector than for the 
TANS state vector. Achieving a perfect match between state 
vectors at the moment of uplink is not actually expected. It 
may be noted that times corresponding to the low point of the 
sawteeth in Figures 2.1 and 2.2 are different. This is because 
the plots were produced with separate simulations, and is not 
due to a miscorrelation between position and velocity updates. 

Although the original intent was to merely compare TANS 
and orbiter generated state vectors, the software produced by 
the NPS team that flew aboard STS-51 provided the means to 
input any pair of state vectors for this comparison. 
Specifically, a similar pair of propagated and GPS derived 
state vectors for SPAS were also available. 
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III. RELATIVE POSITION DISPLAY (ORBITAL SYSTEM) 



A. VBAR/HBAR/RBAR COORDINATE SYSTEM 
1. Definition 

The VBAR/HBAR/RBAR (also referred to as RBAR/VBAR) 
coordinate system is a local vertical/circular (LVC) frame 
used for displaying the relative position of two orbiting 
bodies. This system is precisely the one used by NASA planners 
in planning shuttle maneuvers in close proximity with a target 
satellite. Figure 3.1 shows the background screen used for 
displaying RBAR/VBAR position. It is critically important to 
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Figure 3.1 VBAR/HBAR/RBAR Display Screen 
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note that this is not a rectilinear system, and thus no 
convenient coordinate transformation matrix can be derived. 

The center of the coordinate system is the target 
spacecraft (SPAS for STS-51) . The relative position of the 
chaser spacecraft (Space shuttle Discovery for STS-51) is then 
plotted relative to the target. The horizontal axis is called 
the VBAR. The name is derived from the fact that for circular 
(or near circular) orbits, this axis is generally aligned with 
the target's velocity vector. The vertical axis is called the 
RBAR. So named because it is defined by the target's position 
vector. Displacement along the RBAR is measured positively 
toward the earth and represents an altitude difference between 
the target and chaser. Displacement along the VBAR is measured 
positively in the direction of travel of the target and 
represents a curvilinear distance ahead or behind the target 
measured at the target's altitude. HBAR is displayed 
alphanumerical ly in the upper right hand corner of the screen. 
It represents a north/south 1 distance from the orbital plane 
of the target measured in kft for shuttle orbits. 

2 . Derivation 

Although the RBAR/VBAR coordinate system is not 
rectilinear, it closely parallels a system that is, which is 



’‘Given the orbit for STS-51 had an inclination of 
approximately 28*, HBAR displacement is actually not purely in a 
north/south direction, however north/south is used to denote the 
general direction of displacement. 



12 



often referred to as local vertical/local horizontal (LVLH) . 
There are alternate conventions for determining the direction 
of positive axes in LVLH, but for consistency, these 
directions will parallel those of the RBAR/VBAR frame. 

Coincident with the construction of the RBAR/VBAR 
frame, the corresponding LVLH frame is also derived. Since 
LVLH is rectilinear, it can be specified by a transformation 
matrix from the inertial system in which the input state 
vectors are displayed. This matrix, often referred to as a 
direction cosine matrix (DCM) , will be denoted by the symbol 
L C : . The symbol is read "the transformation matrix from I 
(inertial) to L (LVLH)". The "I" appears on the right hand 
side of the symbol because a column vector in inertial 
coordinates must be placed on the right side of this matrix 
for matrix multiplication to produce the corresponding vector 
in LVLH coordinates. Since the source code for the flight 
software is written in the "C" programming language, where 
zero subscripting is used, the elements of this matrix are 
written 



c,. 


C 01 


Cm 






o 

H 

O 


C 11 


C^2 


c 20 


^21 


C 22 



( 3 . 1 ) 



a. Algorithm 

In producing the RBAR/VBAR coordinates for 
display, it is necessary to construct L C I from input state 
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vector data. State vectors for the target and chaser are 
provided which contain the respective position and velocity- 
vectors displayed in inertial space. Given the position and 
velocity vectors of the target (r t , v t ) , and the position and 
velocity vectors of the chaser (r c , v c ) , the RBAR coordinate 
of the chaser is simply given by the difference in the 
magnitudes of the position vectors 

RBAR = || rj - |rj (3.2) 

The target position vector defines the "z" axis 
of the LVLH frame. Recalling that positive displacement is 
toward the earth, a unit vector along the "z" axis is created 
by negating the normalized target position vector 



z = 




(3.3) 



This unit vector corresponds to the last column of L C I . 

The middle column of L C I is generated by the 
angular momentum vector of the target's orbit. This vector is 
given by the cross product of the target's position and 
velocity vectors 

fi t = r t x v. (3.4) 

A unit vector perpendicular to the orbit plane and along the 
”y" axis can now be created by normalizing this vector. 
However, keeping in mind the desire to have the "x" axis point 
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ahead of the spacecraft, the negated normalized angular 
momentum is used 




(3.5) 



corresponding to the middle column of L C r . 

Recall that the HBAR component represents the 
out of plane component of r c . As the orbital plane contains 
the origin of the inertial system in which r c is measured, 
HBAR is given by the projection of r c onto hy 

HBAR = h z ■ r c (3.6) 

The left column of L C r is produced from the 
orthonormal vectors ^ and t by 

x = y x z (3.7) 

completing the matrix ’"C : 

: C : =[x y z] (3.8) 

The VBAR component represents an angular 
displacement ahead or behind the target spacecraft . To 
determine this value, the projection of r c onto the target's 
orbital plane must be found. Given HBAR is the magnitude of 

A 

the out of plane displacement and hj is a vector in the out of 



-This choice for HBAR appears inconsistent with a right handed 
coordinate system. Since the RBAR/VBAR system is not rectilinear, 
this is of little consequence. Some references, however, may choose 
positive HBAR opposite the angular momentum vector. 
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plane direction, the in plane component of r c (? cop ) is given 
by 



r c . p = r c - HBARh 



(3.9) 



The angular displacement between r cop and r t is then 



r\ = arccos 



r,~ • r, N 

ITZlTr c \ J 



(3.10) 



Unfortunately, computational machines will produce a positive 
number for Equation 3.10 due to the proximity of the 
spacecraft, resulting in an angular displacement without the 
corresponding direction required to determine the sign of 
VBAR. This problem is the motivation for creating L C T while 
computing the RBAR/VBAR coordinates. Consider the vector from 
the target to the chaser 

r dLi = r_ - r„ (3.11) 

Transforming this vector into LVLH coordinates via 

[*:. | - ( 3 - 12 ) 



produces a vector whose "x" coordinate must have the same sign 
as that of VBAR. Modifying the sign of TJ to match the sign of 
the "x" coordinate given by Equation 3.12, VBAR is then 

VBAR = n • |rj (3.13) 

which is an arc length corresponding to the in plane angular 
displacement relative to the target. 
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B. SIGNIFICANCE OF VBAR/HBAR/RBAR 

As previously stated, this is the coordinate system used 
by NASA for planning proximity operations. The reason for this 
is that, to first order, the angular momentum of an orbit is 
constant. For near circular orbits, position and velocity 
vectors are nearly perpendicular, and therefor from Equation 
3.4, an increase in one must correspond to a decrease in the 
other. When two spacecraft fly in close proximity, their 
orbits must have nearly equal angular momentum vectors. In 
this case, a displacement above the VBAR corresponds to a 
larger chaser position vector than target position vector, 
leading to a smaller velocity, and a resulting backward drift 
of the chaser relative to the target. 

Figure 3.2 shows the effect of a posigrade burn for the 
chaser at an instant when the target and chaser have identical 
state vectors. Intuitively, the chaser is expected to move 
ahead of the target. However, this is true only for an 
instant. The increase in velocity will correspond to an 
increase in angular momentum, which in turn corresponds to an 
increase in the semi -major axis of the orbit. The result is to 
cause the chaser to drift above the VBAR, and therefor begin 
to fall behind the target. The bouncing phenomenon shown in 
Figure 3.2 is due to the fact that the point where the 
velocity increase occurs is coincident with both orbits. The 
target, with the slightly smaller semi -major axis, has a 
slightly smaller orbital period, thus reaching this point 
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sooner than does the chaser. The chaser must, however, 
continue to pass through this point every orbit. If the target 
orbit is considered to be purely circular, the additional 
velocity given to the chaser has effectively caused it to have 
a slightly eccentric orbit with a radius of perigee equal to 
the circular radius of the target . 

Figure 3.3 shows a similar situation for a thrust in the 
opposite direction. The argument is the same as for a 
posigrade burn, however in this case the angular momentum is 
decreased, producing a decrease of the chaser's semi -major 
axis and period. The effect is to cause the spacecraft to 
"bounce" forward under the VBAR. 



18 




Spas-GPS 191/06: 12: 15.000 
Orb-GPS 191/06: 13; 10.000 



800.0 



3^K 




9.6K 



6i) K 

f 



-3.2K 



-6.1K 



400.0 



-- 800.0 



bufr 636 
of 2047 



vbar 8.167 Kft 
rbar 663.501 ft 
dlst 8.195 Kft 



SPACE 


FI 


F2 


F 3 


F4 


F5 


F6 


F7 


F8 


F 10 


Alt Menus 


Spas/0- GPS 


Spas/0-INS 


0-GPS/1NS 


Sau - 0R8 


Spas/TGT 


Sau - TGT 


Singl Pred 


Const Pred 


Settings 



Figure 3 . 3 Retrograde Burn 

Proximity operations for the Shuttle are all designed with 
displacements above and below the VBAR to cause the desired 
drift. Each "bounce" represents one orbit, which provides an 
inherent time reference. 

Alphanumeric display of HBAR is useful for the following 
scenario. Ideally, the commander of a mission would prefer to 
match the orbital plane of a given target exactly. This 
requires an occasional thrust to void any out of plane motion. 
If the orbital planes are not matched, HBAR will cycle back 
and forth across the zero position. At an instant when HBAR 
hits zero, the orbiter is in the orbital plane of the target, 
representing an optimal time when a thrust should be applied 
to remove the out of plane motion. 
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IV. RELATIVE POSITION DISPLAY (ORBITER FIXED SYSTEM) 

It is often convenient to express positions in a reference 
frame fixed on the orbiter. This gives the crew the most 
intuitive feel for the information presented. 

At the request of the crew of STS-51, a means of 
presenting the position of SPAS relative to the orbiter was 
produced. The request for this type of display was motivated 
by the size of the crew. Having only a five man crew, all 
crew members slept at the same time. The crew requested the 
ability to locate SPAS when they awoke, so they might know 
where to point other sensors to acquire the target. 

A. SHUTTLE FIXED COORDINATES 

The coordinate system fixed to the orbiter is aligned such 
that, if the orbiter were flying like an airplane, it would be 
aligned with the LVLH system derived in the previous chapter, 
though this is rarely the case. The positive "x" axis points 
directly out of the nose of the orbiter, positive "z" points 
out of the belly of the orbiter, thus forcing positive "y" to 
point out of the right wing. Because this is a rectilinear 
system, a transformation matrix relating this system to the 
inertial coordinate system exists. 

Part of the downlink data stream provided to the software 
was a quaternion known as QBI (Quaternion Body/Inertial) . A 
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quaternion is a four position vector containing information 
relating two coordinate systems. Quaternions are used not only 
for their compactness, but also because of their convenience 
when used in attitude control algorithms. The quaternion QBI 
relates the inertial coordinate system M50 to the orbiter 
fixed or "body" coordinate system. Since we will not be using 
QBI for attitude control algorithms, we have no need to 
perform quaternion algebra, and will immediately create the 
necessary transformation matrix from QBI. 

Given 



QBI = 



g. 

<? 

g : , 

g 4 



(4.1) 



the matrix transformation from inertial to body coordinates 
(referred to as E C : ) is given by [Ref. 3] 



3 C 1 = 



gi + gf - gi - gl 2 ( g 2 q i - g, g 4 ) 2 ( g 2 q. + g, g 3 ) 

2 ( g_ g 3 + g. g 4 ) g : 2 - g| + g 2 - ql 2 ( g 3 g. - g, g 2 ) 
2 ( g 2 g 4 ~ g, g 4 ) 2(g 3 g J +g 1 g 2 ) gf - gl - g| + gi 



(4.2) 



B . PITCH/YAW ANGLES 
1. Definition 

Given E C I , any vector expressed in inertial coordinates 
can be transformed into body coordinates. Specifically, the 
vector from the orbiter to the target can be expressed in body 
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coordinates. However, a vector is still only three real 
numbers, and thus does not offer much intuitive feel for the 
position. To provide intuition, this vector is translated into 
rotation angles through which to put the orbiter so as to 
point the nose of the orbiter on the target. This does not 
imply that the crew should maneuver the shuttle to see the 
target, but rather perform the maneuvers mentally to imagine 
where the orbiter would then be pointing. 

Figure 4.1 shows a typical display screen for the 
Pitch/Yaw plots. The sequence shown in Figure 4.1 suggests 
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Figure 4.1 Pitch/Yaw Plot 



first pitching the orbiter 89.4'; then from the new position, 
yaw the orbiter -5.0*. The final position achieved points the 
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nose of the orbiter directly at the target. This may not seem 
any more intuitive than a vector to someone unfamiliar with 
aviation. However, to an aviator, this clearly implies the 
target is almost directly overhead, slightly to the left. 

The choice of performing a pitch maneuver, then a yaw 
maneuver, is not arbitrary. Most orbiter maneuvers near a 
target spacecraft are performed with the payload bay (top of 
the orbiter) pointing toward the target. If the pitch is 
exactly 90°, and a yaw maneuver had been chosen first, any 
value for yaw would have been acceptable. Thus pitching first 
is chosen with the knowledge that pitch is near 90°, 
eliminating the singularity present by trying to yaw first. 
Had the expected position of the target been near the orbiters 
"x"-"y" plane, an initial yaw maneuver would be more 
appropriate . 

2 . Derivation 

The first step in determining a position relative to 
the orbiter is to produce a vector from the chaser (orbiter) 
to the target (? ct ) via 

r cc = r c - r c ( 4 . 3 ) 

Recall that the position vectors for the target and chaser are 
expressed in inertial coordinates, and therefor Equation 4.3 
gives r ct in inertial coordinates. To express this vector in 
body coordinates, simply apply the coordinate transformation 
matrix B C I created from the quaternion QBI . 
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(4.4) 




'-"l' ] 



Once r ct is expressed 
yaw angles can be produced. F 
problem. The parallelogram 
anchored at the origin has 
sides x, y, and z which are 
the coordinates of ? ct . The 
vector ? p is the projection 
of ? ct onto the "x"-"z" plane 
and is the intermediate 
orientation to be achieved 
after the pitch maneuver. Let 
O be the angle between r p and 
the "x"-"y" plane. Then 0 is 
given by the relationship 



body coordinates, pitch and 
re 4.2 shows the geometry of 




Figure 4.2 Pitch/Yaw Geometry 

the pitch angle sought and is 



tan0 = £ (4.5) 

x 

Let 0 be the angle between ? ct and ? p . Then 0 
represents the yaw angle required to complete the maneuver. 
Since we know the magnitude of ? p is given by 

r p = |Fp| = \/x : + z 2 (4.6) 

then 0 is given by the relationship 
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(4.7) 



tan© = J' 

r p 

As with the standard spherical coordinate system from 
analytic geometry, defining two angles establishes a direction 
toward a point, but not a magnitude. Thus the magnitude of the 
vector r ct is also presented on the Pitch/Yaw Plot display 
screen. 

C . FAST PITCH/YAW 

The Pitch/Yaw algorithm was provided for STS-51 with 
graphics as shown in Figure 4.1, and also alphanumerical ly on 
the RBAR/VBAR screen upon request of the user. Figure 4.3 
shows this display in the upper left corner. 



Spas-GPS 191/04: 12:00.000 
Orb-GPS 191/04: 12: 10.000 

Pitch 52.5 
Yau -4 ,7 

191/04* 09t 45 



800.0 



-- -400.0 



| 

1200.0 



800.0 



1 

400.0 







— I 1 1 

-400.0 -800.0 -1200.0 



-- 400.0 




- “ 800.0 



bufr 313 
of 2047 



RBAR 



vbar 968.446 ft 
rbar 630.310 ft 
di5t 1.162 Kft 



SPACE 


F9 


Alt -FI 




Alt-F5 


Alt -F6 


Alt-F7 


Alt— F8 


Ait-F9 


F10 


Alt Menus 


Toggle 


r reeze Serf 




Pitcft/Yau 


Fast p/y 


Uipe one 


Uipe Plots 


Hbar on/off 


Settings 



Figure 4.3 Fast Pitch/Yaw 
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Clearly, the RBAR/VBAR plots offer the crew the most 
situational awareness of the three families of plots presented 
thus far. However, while observing the RBAR/VBAR screen, the 
crew expressed a desire to have access to the output from the 
Pitch/Yaw algorithm. The Fast Pitch/Yaw option was created to 
provide situational awareness in the orbital reference frame 
as well as the shuttle fixed reference frame. 
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V. RELATIVE MOTION PREDICTION 



A. PROPAGATION 

Input for each algorithm presented are two state vectors 
which define two orbits. To predict the relative motion of the 
two bodies, the Cowell propagator mentioned earlier could be 
invoked to produce future state vectors, which in turn could 
be used in the relative position algorithms discussed in 
Chapter III. Unfortunately, as with any high fidelity 
propagator, the Cowell propagator is computationally 
intensive. To produce 40 predicted points would take 80 calls 
to the Cowell routine. This would not pose a problem if 
performed on a very fast computer. However, the computer in 
which these algorithms reside has a 10 MHz, 386 processor. 
This relatively slow machine does not offer the luxury of 
invoking a high fidelity Cowell propagator 80 times for every 
screen update, and therefor another solution was sought. 

One obvious solution to this problem, is to simply reduce 
the fidelity of the Cowell routine. Flags could be set within 
the algorithm to account for only the central body 
accelerat ion, neglecting accelerations due to higher spherical 
harmonics or drag. This raises the question of accuracy for 
the predicted relative motion. 
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At typical shuttle altitudes, the major perturbing 
acceleration for an orbit is due to the second zonal harmonic, 
often referred to as the J 2 term. The acceleration due to J 2 
is roughly two orders of magnitude larger than any other 
perturbing acceleration. Effects due to J 2 on an orbit viewed 
in inertial space are often evident within one orbit, thus 
neglecting this term may initially seem unwise. There is, 
however, an interesting property of all spherical harmonics 
that justifies their exclusion for the purposes of predicting 
relative motion. 

Accelerations due to spherical harmonics are a function of 
position relative to the center of the pseudo-spherical body 
about which the satellite is orbiting. The potential of the 
earth's gravity field, or geopotential, is given by 



v = ^ 

“r 



/ \ •* 

-?| P,. (sin<J>) (C r _cosmX + S r ,sinmX.) 



( 5 . 1 ) 



where the parameters are defined to be: 

V e = Geopotential function 

= Gravitational constant of the earth 
r = Magnitude of the radius vector 

a = Semi-major axis of the central ellipsoid (earth) 
n,m = Degree and order of each term 
0 = Geocentric latitude 
X = Geocentric longitude 

c nm , s nm = Normalized gravitational coefficients 
p rm = Normalized associated Legendre functions 

N = Number of terms to be used 
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The terms c r!r/ s r , , and a are determined by the geopotential 
model used for evaluation (GEM 10B for STS-51) . What is 
noteworthy here is that the terms <t> 7 X, and r are functions of 
the coordinates of the position vector expressed in the Earth 
Centered/Earth Fixed coordinate system that is tied to the 
geopotential model. Recognizing that the acceleration caused 
by this function is merely the gradient of V®, then too must 
acceleration be a function of position. 

Recall that the intent is to apply these accelerations to 
two bodies in very similar orbits, thus having very similar 
position vectors. For proximity operations, the vector from 
the orbiter to the target is rarely much more than two tenths 
of a percent of the corresponding radius vectors. Thus the 
accelerations caused by spherical harmonics for the orbiter 
are nearly equal to those of the target. Therefor their effect 
on relative motion can be neglected for short propagations, 
corresponding to the neglect of the double summation term in 
Equation 5.1. 

The other acceleration which we hope to neglect is that 
caused by drag. The drag model used for the Cowell propagator 
is based on the Jacchia density model, which computationally 
speaking, is not a trivial calculation. Drag accelerations are 
a function of velocity, density, and ballistic coefficient. 
Applying the same reasoning used relating the position vectors 
of chaser and target, it is argued that velocities must be 
nearly the same for similar orbits. Atmospheric density for 
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the two bodies is nearly identical due to the similar position 
vectors. However, the ballistic coefficient is a function of 
the shape and mass of a body and is thus fairly dissimilar for 
the orbiter and a much smaller satellite. It is precisely this 
difference that limits the validity of propagation without a 
drag acceleration. Drag effects become significant in a matter 
of days, thus neglecting them for more than a few orbits is 
not recommended. 

Having justified a low fidelity propagator for relative 
motion prediction improves the time problem imposed by the 
relatively slow processor. It however does not speed the 
calculations to the point that they could be included. 
Calling a numerical integrator 80 times proved to take too 
long regardless of the simplicity of the acceleration term. A 
faster method was still required. 

B. f AND g FUNCTIONS 

The f and g functions, and their corresponding time 
derivatives, represent the basis for the standard 
parameterization of position and velocity along an ellipse in 
3-space. They are as close as possible to analytic functions 
of time as can be produced for propagation in cartesian 
coordinates . There is one very short convergent numerical 
algorithm needed to evaluate the f and g functions. However, 
the associated function evaluations are very simple, and 
convergence nearly always occurs within two or three iterations. 
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Construction of the f(t) and g(t) functions requires an 
initial position vector and an initial velocity vector. As an 
intermediate step in the determination of f(t) and g(t), four 
of the cartesian elements that describe the orbit must be 
calculated. When time is input, a corresponding eccentric 
anomaly is calculated numerically, and a new position vector 
can be produced via [Ref. 4] 

fit) = — [cos ( E ( t ) - E 0 ) - l] + 1 

git) = t + i[sin(E(t) - E 0 ) - (E(t) - E c )] (5 ' 2) 

r ( t) = f it) r 0 + git) v 0 

Correspondingly, velocity being the time derivative of 
position, a new velocity is then 

fit) = - nsin(E(t) - EJ 

r(t) r 0 

git) = — £_ fcos ( E ( t ) - E, ) - ll + 1 (5 * 3) 

rit) L - J 

v(t) = f it) r 0 + git) v z 

The problem of determining future position and velocity as 
a function of time rests on evaluation of the right hand sides 
of Equations 5.2 and 5.3. Given that the inputs will be 
initial position and velocity vectors, whose magnitude is 
given by 

r c = ||r c || v 0 = |vj (5.4) 

the specific energy of the orbit is given by 
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and the semi-major axis (a) is 



(5.6) 



a 



Tr 



The angular momentum vector and corresponding magnitude 
for the orbit 



H = r_ x v_ 
h = |JJ| 



(5.7) 



are assumed constant. The eccentricity vector, given by 




(5.8) 



points toward perigee and has magnitude 

e = || e || (5.9) 

equal to the eccentricity of the orbit. The true anomaly (v 0 ) 
corresponding to this point is obtained from [Ref. 5] 



r . • e 

cos v = — — 
r e 



sin v o = 
tan v 



H ■ ( e x r r ) 
h e r 0 

sinv o 

cos 

o 



(5.10) 



Given the initial true anomaly, the initial eccentric anomaly 
(E ) can then be found from [Ref. 1] 



tan 



( 5 . 11 ) 



- tan 




IZJ 

1 + e 



It will also prove convenient to define the initial mean 
anomaly (M & ) via Kepler's equation 



The final parameter needed for Equations 5.2 and 5.3 is the 
mean motion (n) of the orbit, given by 



Note that the calculations represented by Equations 5.4 
through 5.13 need not be performed 80 times to produce the 
theoretical 40 relative positions, but rather twice (once for 
the chaser, and once for the target) . To evaluate Equations 
5.2 and 5.3 for a given time (measured positively from t=0 => 
r 0 ,v 0 ) requires the mean anomaly as a function of time from 



and the numerical solution of Kepler's equation for the 
eccentric anomaly at that time 



The solution of Equation 5.15 is found by applying the 
Laguer re -Conway algorithm [Ref. 1], which is an iterative root 
solver. Because the function evaluations are not complex, and 



M c = E c - e sin (E c ) 



( 5 . 12 ) 



n 



N a :< 



( 5 . 13 ) 



M( t) = M, + n t 



( 5 . 14 ) 



M( t) = E(t) - e sin (E( t } ) 



( 5 . 15 ) 
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the orbits of interest are near circular, convergence never 
takes more than three iterations. 

With e, a, and E(t) in hand, the magnitude of the radius 
as a function of time (r(t)) is 

r( t) = a ( 1 - ecos (E( t) ) ) ( 5 . 16 ) 

completing the list of necessary terms for evaluation of 
Equations 5.2 and 5.3 for times beyond that corresponding to 
the initial position and velocity. 

Equations 5.14 through 5.16 are the only calculations that 
must be performed for each time of interest, providing a very 
fast means of propagation in cartesian coordinates. 
Specifically, this algorithm is fast enough to be performed 
continuously so as to provide a means of having a constant 
prediction of future motion. 

C . FUTURE PLOTS 

Keeping in mind that maneuvers are normally performed near 
the VBAR, this algorithm provides a means of predicting when 
a maneuver will be needed, as well as giving some intuitive 
feel for what maneuver should be performed. Figure 5.1 shows 
an RBAR/VBAR display screen with the Future Plot option 
selected. The number of points to display and interval between 
points are user defined options. For this simulation, 40 
points at an interval of three minutes are used. Prediction 
begins where the curve turns from solid (history) to numbered. 



34 




Figure 5 . 1 Future Plot 



At 40 increments, or two hours, the orbiter will be cresting 
just above the VBAR. This point, or the initial predicted 
crest (at 11 increments), correspond to the points where 
maneuver should be performed to affect a rendezvous. 

D . FUTURE THRUST 

Given that the astronauts have some physical intuition for 
the type of maneuver that should be performed given a position 
and motion displayed on an RBAR/VBAR plot, use of the Future 
Thrust algorithm provides an opportunity to refine the thrusts 
required to perform a rendezvous. The first step is to use a 
Future Plot to note the time that a maneuver should be 
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performed. The user then initiates the Future Thrust algorithm 
with a predicted thrust and thrust time. Future Thrust uses 
the f and g functions to propagate the state vectors to that 
time, and then applies the input velocity change (thrust), and 
propagation continues. If the continuation of the Future Plot 
does not intersect the desired point, then the user simply 
modifies the input thrust. Because this algorithm is so fast, 
modifying the thrust settings appears to immediately vary the 
track displayed on the Future Plot, thus providing a means of 
"walking" the track onto a desired point (presumably near the 
target) . 

Velocity changes are normally expressed in LVLH 
coordinates, however they do not represent a derivative with 
respect to a moving frame. They are in fact inertial 
derivatives simply expressed in a convenient frame. The 
familiar transformation matrix I C L is used to transform the 
velocity changes into inertial coordinates. The transformation 
matrix L C X , produced in Chapter III, consists of three 
orthonormal basis vectors, and therefor the inverse of L C X is 
merely its transpose. 

The user inputs to this algorithm are a time to affect the 
thrust, which is set on a separate screen, and the thrusts 
applied at that time, controlled via keys when the RBAR/VBAR 
screen is active. Figure 5.2 shows a Future Thrust screen 
created during the same simulation that created Figure 5.1. 
The user has chosen to perform the thrust at the first VBAR 
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crossing. The inner numbered curve represents the predicted 
path after the thrust, while the outer numbered curve is the 
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Figure 5 . 2 Future Thrust 

predicted path if the thrust command is ignored. The LVLH 
thrusts in the "x" and "z" direction are displayed within the 
menu bar. These correspond to values to be programmed into the 
orbiter's control system for activation at the predicted time. 



E . RENDEZVOUS PREDICTION 

In the purest sense, Future Thrust does not represent a 
rendezvous algorithm. No rendezvous solution is provided. 
However, given the intuition of the astronauts, this algorithm 
provides the opportunity to evaluate the effectiveness of 
proposed thrusts before they are performed. Operationally, 
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thrust commands are calculated on the ground and then 
uplinked. The crew merely performs the commanded maneuvers. 
These algorithms provided a means of viewing the results of 
ground directed thrusts on orbit. To this end, these 
algorithms enhance the situational awareness of the crew, and 
provide an independent means of validating ground commands. 
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VI . RENDEZVOUS SOLUTION 



The methods discussed in this chapter represent one way to 
predict the velocity changes needed to affect a rendezvous. 
Although it was possible to stretch the requirements of DTO 
700 to provide information that increased the situational 
awareness of the flight crew, rendezvous prediction was in no 
way addressed in DTO 700. Essentially, as long as no 
information was provided that could be used to control the 
orbiter, experimentation with algorithms was permitted. 
Producing the thrusts required to affect a rendezvous are 
indeed control inputs. To be considered for flight, a control 
algorithm has to undergo strenuous testing. Given there was 
insufficient time for such testing, the algorithms presented 
in this chapter were not included in the primary executable 
that flew on STS-51. The rendezvous initiation portion of this 
algorithm was, however, available in a backup executable, 
should a need for its output have arisen. 

A. LINEARIZED EQUATIONS OF RELATIVE MOTION 
1. Coordinate System 

This treatment is taken from Reference 1. To express 
the equations of relative motion, a convenient coordinate 
system must be used. The author has chosen a system as yet 
unaddressed in this thesis. It is essentially an alternate way 
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of creating an LVLH frame, which is an orthonormal frame tied 
to orbital motion. This frame is not coincident with the 
previously derived LVLH coordinate system. It will again be 
denoted with an "L" superscript, but care must be taken in 
avoiding the mistake that this transformation matrix is 
equivalent to that derived in previous chapters. 

For this new coordinate system, the positive "y" axis 
is defined by the normalized radius vector of the target 



y = 



r r 

17-11 



( 6 . 1 ) 



while the "z" axis is defined by the normalized angular 
momentum vector of the target 



z = 



7 

17 . || 



( 6 . 2 ) 



forcing the "x" axis to be given by 

x = y x z (6.3) 

Note that the "x" axis now points opposite the direction of 
travel. These orthonormal vectors define the columns of the 
transformation matrix from inertial to LVLH coordinates 



L C : = [x y z] (6.4) 

2 . Equations of Motion 

The linearized equations of relative motion make use 
of two significant simplifications in their derivation. First, 
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the angular displacement between the target and chaser is 
assumed to be small. Recall a similar assumption was made in 
justifying the use of the f and g functions in Chapter V. 
Secondly, the equations are based upon the assumption that the 
target's orbit is circular. This second assumption is more 
restrictive than the treatment given in Chapter V. Shuttle 
orbits are in fact nearly circular. However, the assumption of 
a circular orbit does introduce a source of error. 

The equations of motion are expressed in terms of 
initial relative position and velocity components as a 
function of time. Relative position is 



x = x + 2^ : ( 1 - coscot ) 
(0 



( 4 i C ° - 6y_ 

l <«> J 



sincot + ( 6(0y o - 3x,)t 



y = 4y - 2 - c + 

co 



i 2 ~ : ~ 

l 0) 



(6.5) 



3y. 



y 

coscot + - sincot 
CO 



z = - sincot + z. coscot 
co 



and relative velocity is given by 

x = 2y c sincot + ( 4x 0 - 6coy. ) coscot + 6coy 0 - 3x 0 
y = ( 3coy 0 -2x 0 ) sincot + y c coscot ( 6 . 6 ) 

z = z_coscot - z, sincot 

The term co in these equations is the orbital angular 
rate of the assumed circular orbit of the target. The 
corresponding term for elliptical orbits is the mean motion 
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(n) . Without loss of generality, the mean motion for the 
target will be used instead of co within the following 
algorithms. Note that velocity terms in Equations 6.5 and 6.6 
are truly derivatives with respect to the non-inertial frame 
LVLH. In addition, the simplifying assumptions result in the 
"z" or "out of plane" equations becoming uncoupled. 

For a given initial relative position and prescribed 
time, solving the homogeneous form of Equations 6.5 for the 
initial relative velocity terms (x., y c , and z Q ) produces the 
required initial relative velocity to begin a rendezvous. 



_x r 

0) 



Yr 

‘go 



x, s incot + y [ 6cot s incot -14(1 - coscot ) ] 



3cotsincot -8(1 - coscot) 






x r 

co 



- 6y 



s incot + ( 6(0 y 3 - 3x r ) t 



(6.7) 



-2(1- coscot ) 



r d 

co tancot 

With these velocities, the initial relative position, and the 
prescribed rendezvous time; Equation 6.6 can be solved for the 
terminal relative velocity which must then be negated in order 
to complete the rendezvous. 



The "y" component of Equation 6.7 differs from that presented 
in reference 1. The author's equation could not be reproduced, and 
furthermore did not produce a rendezvous solution during 
simulation . 
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B . ALGORITHM 



1. Rendezvous Initiation Thrust 

As in all algorithms presented in this thesis, the 
input is a pair of concurrent state vectors. Also required is 
an input time desired to perform the rendezvous. Since 
Equations 6.6 and 6.7 do not require the chaser to be on the 
VBAR, times that are integral multiples of orbital periods 
should be avoided. This is because at these times the 
spacecraft is condemned to pass through the same point again, 
and if that point is at the wrong altitude, the algorithm will 
try to produce huge changes in radial velocity in order to 
obtain the desired altitude. 

Given a rendezvous time, parameters used in Equation 
6.7 must be determined. Recall the position and velocity 
vectors for chaser and target are provided as inputs. Thus, 
the vector from target to chaser (? d ) is given by 




The subscript "I" is used as a reminder that the equation is 
expressed in inertial coordinates. The following equations 
contain inertial and non-inertial derivatives. Vector 
equations which do not perform a coordinate transformation 
will be subscripted to denote which coordinate system the 
equation is expressed in. 
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Construction of the matrix L C I as a function of the 
target state vector is outlined in Equations 6.1 through 6.4. 
The difference vector is expressed in the new coordinate 
system by 

hi = - [' ] : < 6 - 9 > 

where the components of the left hand side vector of Equation 
6.9 represent the variables x Q , y Q , and z c of Equation 6.7. 

As previously noted, the orbital angular rate (co) is 
represented using the more general concept of mean motion (n) , 
which in turn requires a value for the semi -major axis of the 
target orbit. Given target position and velocity vectors 

r. = 1?. | v t = flvj (6.10) 

the relationship between radius, speed and semi -major axis 




can be solved for the semi -major axis 

= r th3> 

- r t v t 2 



( 6 . 11 ) 



( 6 . 12 ) 



The mean motion (or orbital angular rate in this case) is 
finally given by 
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co = n 



(6.13) 






providing the last parameter required to solve Equation 6.7 
for the initial relative velocity necessary to start the 
rendezvous . 

The solutions produced by Equation 6.7 are clearly 
components of a velocity vector. The problem is to relate this 
relative velocity to a desired change in the chaser velocity 
vector. The vector created by Equation 6.7 is the time 
derivative of the difference vector created with Equations 6.8 
and 6.9. The crucial point is that it is a derivative with 
respect to the LVLH frame and not with respect to inertial 
space. To relate derivatives taken with respect to two 
different frames, the relationship 

+ Wxf (6.14) 

dt dt 

is used, where the term *c3P is read "the rotation rate of 
coordinate system B with respect to coordinate system A" . In 
terms of the coordinate systems used, 



1 dr 



d _ 



dt 



d fj 
dt 



6b- x r . 



(6.15) 



where the derivative on the right hand side is with respect to 
LVLH (superscript "L") and is the output of Equation 6.7, and 
I c3f‘ expressed in LVLH coordinates is simply 
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( 6 . 16 ) 



Equation 6.15 provides the means to evaluate the time 
derivative of the difference vector with respect to inertial 
space. However, note the left hand side of Equation 6.15 
represents the difference of the velocity vectors. 



' d fj _ 1 dr. _ ' dr t 
dt dt dt 



( 6 . 17 ) 



Equation 6.15 is expressed in LVLH coordinates, while Equation 
6.17 is expressed in inertial coordinates. To transform to 
inertial coordinates, the results of Equation 6.15 must be 
left multiplied by the inverse of L C r (which is its transpose) 
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( 6 . 18 ) 



providing the means to solve Equation 6.17 for the desired 
chaser velocity in inertial coordinates 



v„ = 



'dr, 

dt 



+ v. 



( 6 . 19 ) 



The chaser velocity given by Equation 6.19 is the 
desired velocity expressed in inertial coordinates needed to 
affect a rendezvous. Recall a value for v c was input to this 
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algorithm. The input value represents the current chaser 
velocity, while Equation 6.19 gives the desired chaser 
velocity. Differencing these produces the desired velocity 
change to affect the rendezvous 



Ai? = ■ - PJ 



Old 



( 6 . 20 ) 



which, though produced in inertial coordinates, can be 
expressed in any convenient coordinate system given the 
transformation matrices created in prior chapters. 

2 . Rendezvous Termination Thrust 

Although initially tested with the software designed 
for STS-51, this portion of the algorithm has since been 
removed, and did not fly in any form as part of DTO 700. As 
will be shown, the Av produced by this algorithm is based on 
information as old as the chosen time to rendezvous. Said 
another way, as a rendezvous proceeds, more timely information 
becomes available, thus antiquating this solution. 

To produce the desired rendezvous termination thrust, 
the initial relative velocity for the rendezvous was found 
from Equation 6.7. The results of Equations 6.7, 6.8, 6.9, 
6.13, and the desired time to rendezvous, are all of the 
inputs needed to solve Equation 6.6 for the relative velocity 
at the end of the maneuver. Applying Equations 6.15 through 
6.19 to the output of Equation 6.6 produces the inertial 
velocity at the end of the rendezvous ellipse, which 
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corresponds to the old chaser velocity vector of Equation 
6.20. Clearly, the desired new chaser velocity should be 
identical to the target velocity. It may be assumed that the 
position vector difference is zero, since that is how the 
algorithm began. 

The target state vector must be propagated through the 
desired time to rendezvous, in order to produce the 
transformation matrix of Equation 6.18, and the target 
velocity vector of Equations 6.19 and 6.20, before applying 
Equations 6.15 through 6.20. 

During the testing of this algorithm, the Cowell 
propagator was used to produce the target state vector at 
rendezvous termination. However, since the solution of the 
equations of relative motion, and the solutions produced by 
the f and g functions are based on many of the same 
assumptions, propagation with the f and g functions were 
considered equally valid. 

C . APPLICATION 

Rendezvous maneuvers for the Shuttle are typically 
performed on the VBAR. However, should the need arise, this 
algorithm is not so constrained. Figure 6.1 shows the display 
screen associated with the algorithm. Because inclusion of 
this algorithm was a relatively low priority item, the actual 
thrusts computed are displayed on a separate screen. In this 
display, the algorithm is coupled with the Future Thrust 
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algorithm. The solution for the desired Av is directly input 
to the Future Thrust algorithm with zero time delay. The 20 
time increments shown in Figure 6.1 correspond to a one hour 
"look ahead" for Future Plot. Coincidently , one hour is the 
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Figure 6.1 Rendezvous Predictor 



prescribed time input to the rendezvous initiation thrust 
algorithm. The figure shows that it will take 30 minutes to 
reach the VBAR. With the standard methods of maneuvering on 
the VBAR, it would then take another orbital period (=90 
minutes) to affect a rendezvous. The numbered curve that shows 
the abrupt change in direction results from the rendezvous 
initiation thrust algorithm, and demonstrates a means for 
rapid rendezvous not available with current methods. 
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VII. RENDEZVOUS SOLUTION (REVISITED) 

The previous chapters address the theory behind the 
algorithms that resided in the NPS software that flew as part 
of DTO 700 on STS-51. However, this software was not designed 
such that it could only support STS-51, but rather it can be 
molded to provide operationally significant information given 
any source of state vectors. The crew of STS-60, scheduled for 
a December launch, is currently planning on using some version 
of this software during their mission. Furthermore, much of 
the functionality of the NPS software is coincident with that 
of another program more commonly used by NASA. There is 
currently much interest in merging the two programs, producing 
an ultimate rendezvous and proximity operations tool. Because 
the software created by the NPS team is still very much in the 
spotlight, continuing to address the problems of rendezvous 
and proximity operations is prudent. 

This chapter will readdress the problem of producing the 
necessary thrusts required to affect a rendezvous, given a 
prescribed rendezvous time. The treatment is taken from 
Fundamentals of Astrodynamics [Ref. 6], and is more general 
than the methods of Chapter VI. The algorithm is based on the 
use of the f and g functions, thus benefiting from the 
assertions to their validity in proximity operations put 
forward in Chapter V. 



50 



A. THE GAUSS PROBLEM 



The Gauss Problem is a general term associated with the 
problem of orbit determination from observations at specific 
times. In this chapter, the problem of orbit determination 
given two position vectors and a time between them will be 
addressed. The brilliant German mathematician, Carl Friedrich 
Gauss, did not have the luxury of being presented complete 
position vectors, but rather had only the right ascensions and 
declinations of three observations. The methods used by Gauss 
are, however, equally valid for the more simply stated 
problem. 

1 . Formulation 

Inputs for the Gauss Problem are two position vectors 
and a time. However, as with all algorithms in this thesis, 
the information provided consists of two concurrent state 
vectors, and a desired time to rendezvous. To formulate the 
Gauss Problem, the position vector of the chaser may be used 
directly. However, the second point in the rendezvous ellipse 
will be a point occupied by the target after the time to 
rendezvous has elapsed. In other words, the target state 
vector must be propagated through the time to rendezvous to 
produce the second position vector. Both rendezvous ellipse 
and the future target position will be produced with the f and 
g functions, neglecting perturbing accelerations, invoking the 
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assertions of Chapter V as to the relative accuracy of the 
solution . 

The two input vectors for the Gauss Problem are 



r i = 



v 




(7.1) 



where the "t" subscripted vectors are those for the target at 
the time of rendezvous. The velocity vectors are not required 
for the Gauss Problem, however they will be required later to 
produce the thrusts necessary to begin and terminate the 
rendezvous . 

2. Solution 

Before addressing the solution to the Gauss Problem, 
the difference in true anomalies (Av) for the two position 
vectors is needed. Calculation of Av using an inner product is 
insufficient, since it does not give the sign of Av, which is 
also important. Given the position vectors and magnitudes 



r, = Ir. 



r = r 



(7.2) 



the difference of true anomalies is found from 



cos (Av ) = — 

r i r 2 



sin 



. f r , x r . ) ( r , x v r 

(Av) = — i • ™ 

^ r.r. J ( ||r r x v r |) J 

tan (Av ) = sin ;^j 
cos (Av) 



(7.3) 
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The second term in the sine equation is the normalized angular 
momentum vector for the target's orbit. Ideally, the angular 
momentum vector from the transfer ellipse should be used. 
Since it is unavailable, this term serves as a good 
approximation for similar orbits. 

As previously stated, this algorithm is dependent on 
the use of the f and g functions introduced in Chapter V. The 
form used to calculate the values for f, g, and their 
derivatives varies from that used previously. This is due to 
the iterative method used in solving the problem. It will 
prove convenient to choose the semi-latus rectum (p) as the 
variable to iterate on, forcing an additional form of the f 
and g functions. 



r. 



f = 1 --Ml - cosAv) =1 - - ( 1 - cosAE) 

p r. 



r.r-sinAv 

g = -J—i = t - 
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? tanl 
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(AE - sinAE) 



(7.4) 
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Recall, the f and g functions define the rendezvous ellipse by 
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(7.5) 



r 2 = fr i + gv 1 
v 2 = fr, + gv 1 

Since the position vectors in Equation 7.5 are known, the 
Gauss problem is reduced to solving for the scalars f, g, f, 
and g . 

Since it can be shown that one of the expressions in 
Equations 7.4 is dependent, we have three equations in seven 
variables ( r : , r 2 , Av, t, p, a, and AE) . However, four of these 
variables are known r 2 , Av, and t) . The problem is then 

to solve three transcendental equations in three unknowns. 
Many iterative methods are available, however a particularly 
elegant method is taken from Reference 6. 

3 . p-Iteration Method 

There are many advantages to the p-iteration method. 
One of particular importance for numerical computing, is that 
this method allows the implementation of a Newton iteration 
for convergence. The elegance of this method stems from the 
fact that the semi-latus rectum (p) can be expressed in terms 
of three of the known variables and only one of the unknowns. 

r x r 2 ( 1 - cosAv ) 

~ * - Av ~Ke (7.6) 

ri + r 2 — 2y]r l r 2 cos — cos — 

Likewise, the semi-major (a) axis can be expressed in terms of 
the single variable p by 
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a 



MKp 

( 2M - L 2 ) p 2 + 2 KLp - K 2 



(7.7) 



where the parameters M, K, and L are directly calculated by 

K = r 1 r 2 ( 1 - cosAv) 

L = r j + r 2 (7.8) 

M = r x r 2 ( 1 + cosAv) 

For a guessed value of p, the formulas presented thus 
far provide the means of solving for t in the second formula 
of Equations 7.4 (this will be outlined in summary) . The 
question then becomes; how to pick an initial value for p, and 
how to update p between iterations. 

The methods for guessing an initial p presented by 
Bate, Mueller and White are much more general than is required 
for the present problem. A transfer ellipse similar to the 
target and chaser orbits is required. These orbits are nearly 
circular (e = 0). Specifically, since semi-latus rectum is 
given by 

p = a ( 1 - e 2 ) (7.9) 

an average of the two radii, conveniently given by 



Pc 




+ r 2 
2 



L 

2 



(7.10) 



represents an outstanding initial value for semi-latus rectum. 

As previously mentioned, the p-iteration method 
provides a means of using a Newton iteration for updating the 
values of p. Recall that a guessed value of p eventually 
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produces a value for time (t n ) in Equation 7.4. To update p, 
the Newton iteration 



Pr.< 



= Pr. 




( 7 . 11 ) 



requires the evaluation of the derivative of time with respect 
to semi-latus rectum at the guessed value of p. A 
straightforward calculation provides this derivative as a 
function of variables either known or calculated during the 
iteration . 
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( 7 . 12 ) 



Equation 7.12 represents the derivative corresponding to an 
elliptical transfer orbit. A hyperbolic solution may also be 
possible (requiring a different formula) , but such a transfer 
orbit would require an inordinate amount of energy to be 
expended. Therefor, only Equation 7.12 will be considered. 



B . ALGORITHM 

Given concurrent state vectors for the target and chaser, 
and a desired time to rendezvous, the following steps will 
provide a rendezvous ellipse based on the two body solution as 
embodied in the f and g functions: 

1. Use the f and g algorithms discussed in Chapter V to 
propagate the target state vector to the time of 
rendezvous. This state vector represents position 2 for 



56 



the Gauss Problem. Position 1 is represented by the 
current chaser state vector. 

2. Calculate the difference in true anomalies with Equation 
7.3. 

3. Calculate the parameters K, L, and M with Equation 7.8. 



4. Guess an initial value for the semi-latus rectum with 
Equation 7.10, and initialize t n at zero. 



While 1 1 — t n 1 > 

rendezvous ) 
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5 through 9 
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with the Av 


formulation 


of 



Equation 7.4. 



6. Rewriting the AE formulation of Equation 7.4 

cosAE = 1 - - - ( 1 - f ) 
a 

sinAE = — - r (7.13) 
n la 

canAE = sim y 
cosAE 

solve for AE. 

7. Using the AE formulation for g in Equation 7.4, solve 
for t n . 

8. Calculate dt/dp from Equation 7.12 using t r and p r . 

9. Produce the next guess for p with Equation 7.11. 

Assuming |t-t n | is adequately small, the last values for p, a, 
and AE are now acceptable. 

10. Calculate f, g, f, and g with Equation 7.4. 

11. Solve for v x in the first formula of Equation 7.5. 

12. Solve for v 2 in the second formula of Equation 7.5. 

13. Solve for the rendezvous initiation thrust (Av : ) via 
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(7.14) 



Av : = v. - v c 

14. Solve for the rendezvous termination thrust (Av 2 ) via 

Av 2 = v t - v 2 (7.15) 



C . ADVANTAGES 

Compared to the rendezvous solution produced with the 
linearized equations of relative motion, this algorithm has 
two very distinct advantages. First this algorithm is clearly 
more general. There is no near circular orbit assumption, and 
the algorithm is valid regardless of the relative distance 
between target and chaser. The quality of the solution will 
decrease slightly because of accuracy lost in not accounting 
for perturbing accelerations, however this method will still 
get the chaser in the neighborhood of the target 4 . 

The second advantage is the ability to bias the algorithm 
to a particular size orbit . The linearized equations of 
relative motion offer no means of sizing an orbit. Both 
methods produce an ellipse constrained with two positions and 
a time. However, there is not a unique solution to this 
problem. For example, assume the time constraint is two hours. 
The rendezvous ellipse may be one that passes through the 
rendezvous point once before rendezvous, or it may be the more 



4 The method of determining Av in Equation 7.3 does require the 
orbits to be nearly coplaner. 
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eccentric ellipse that just reaches the rendezvous point at 
the two hour point. The linearized equations of motion offer 
no convenient means of specifying which ellipse is desired. 
With the algorithm presented in this chapter, the opportunity 
to modify the values for Av at step 2, and AE at step 6 is 
available. For example, a nominal period is roughly 90 
minutes. If two hours is chosen as the time to rendezvous, Av 
and AE may be increased by a factor of 2k to allow for the 
rendezvous during the second orbit of the rendezvous ellipse. 
This method of biasing the size of the rendezvous ellipse 
translates into smaller thrusts, and a rendezvous that "walks" 
toward the target . 

Figure 7.1 shows the results of a simulation for which the 
time to rendezvous was four hours. Since this time lies 
between the nominal two and three orbit times, a factor of 4 n 
was added to Av and AE at the appropriate steps. The dotted 
curve is the result of a posigrade separation maneuver. When 
the chaser reached the VBAR, the rendezvous was initiated. The 
smooth curve is the path traveled along the rendezvous 
ellipse. The simulation was run with a high fidelity Cowell 
propagator, while the rendezvous solutions are produced with 
the f and g functions. Although the rendezvous was initiated 
over 6,400 feet away, the rendezvous termination thrust 
occurred at a point less than 20 feet from the target. 

In a very practical sense, the two time constrained 
rendezvous algorithms presented apply directly to a rendezvous 
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Figure 7.1 p-Iteration Rendezvous (4 hr/+2 orbit bias) 



method currently employed by NASA. Current rendezvous 
techniques [Ref. 7] are initiated by maneuvers on the VBAR 
which amount to phase corrections for spacecraft in the same 
orbit with a phase difference. The first direct rendezvous 
targeting is performed on the "bounce" prior to passing the 
target, and initiates an angularly constrained rendezvous with 
a point approximately 400 feet from the target. While on this 
rendezvous ellipse there are maneuvers known as Midcourse 
Corrections (MC’s) performed to refine the 400 foot point. 
Translating the angular constraint to a time constraint, and 
constraining the time at the 400 foot point provides an ideal 
opportunity for the employment of these algorithms. 
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VIII. POST FLIGHT DATA 



As previously mentioned, with the exception of the state 
vectors provided by the TANS GPS receiver, all information 
used by the algorithms presented in this thesis, was stripped 
from the downlinked data stream. Mr. Tom Silva, the gentleman 
responsible for the software that did the stripping, also had 
the foresight to record the downlinked data at the Johnson 
Space Center. He then designed software that provided the 
means to replay this recorded data through the flight 
software. An exhaustive analysis of the NPS software with 
recorded flight data would take months, and very likely will 
be the subject of future theses. This chapter will concentrate 
on the periods just before and after the rendezvous with SPAS 
highlighting the usefulness of these algorithms as an on 
orbit, and post-flight debriefing tool. 

A. ON ORBIT 

1. State Vector Quality 

A common phrase among computer programmers is "Garbage 
in, garbage out." This phrase is entirely applicable to the 
NPS software. The algorithms accept state vector inputs. 
However, if the input state vectors do not accurately 
represent the position and velocity of the bodies of interest, 
the solution produced by any of these algorithms will be 
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equally flawed. The primary state vectors of interest are 
those produced by the computers of the orbiter and SPAS. Both 
of these involve propagation, and thus accrue error. However, 
as the orbiter approaches the target, a KU band radar aboard 
the orbiter illuminates the target producing very accurate 
relative position and velocity information. Within the 
orbiter 's computers, the orbiter state vector is slaved to 
match the relative information produced by the KU band radar. 
Although the true positions and velocities of the bodies may 
not necessarily be contained in their respective state 
vectors, the errors have become identical, producing the ideal 
scenario for the relative motion algorithms contained in the 
NPS software. 

2 . Terminal Initiation 

The Terminal Initiation (TI) burn marks the beginning 
of a direct rendezvous using standard NASA rendezvous 
procedures [Ref. 7]. Prior to TI, the chaser is "bouncing" 
beneath the VBAR toward the target. The "bounces" are designed 
such that if no maneuvers are performed, the chaser will pass 
harmlessly beneath the target. The TI burn is performed at the 
last apogee prior to passing beneath the target, and is 
designed to begin a rendezvous that will be complete in 320’. 

The constraints imposed by NASA on the various 
maneuvers performed during rendezvous are complicated and 
involve the consideration of much more information than is 
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available to the NPS software. However, NASA is equally 
hampered by the problem of inaccurate state vectors used for 
calculation. The calculations for the TI burn are performed 
during the orbit prior to TI by ground controllers, and are 
then uplinked to the crew of the orbiter. 

Figure 8.1 shows a Future Thrust display screen at 
about the same time the TI burn parameters become available. 
The inner numbered curve shows that the orbiter will pass 
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Figure 8.1 TI Burn (initial look) 

slightly ahead of the target, which is exactly the desired 
flight path. 

Leaving the Future Thrust option active as the orbiter 
approaches TI begins to tell a different story. As the orbiter 
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gets closer to the target, the orbiter state vector becomes 
slaved to the target state vector via KU band radar 
information. As the relative error between the state vectors 
decreases, the Future Thrust algorithm begins to show that the 
orbiter will not even reach the RBAR as the result of the TI 
burn. Figure 8.2 shows a Future Thrust display screen just 
prior to TI . The operator of this software. Dr. James Newman, 
had the ability at this point to incrementally vary the TI 
burn parameters so as to "walk" the predicted trajectory 
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forward of the target. However, considering the experimental, 
and entirely unproven nature of the NPS software, this would 
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probably not have been a tremendously wise choice, in spite of 
it's availability. 

Armed with the results of Figure 8.2, and the Future 
Plot screens produced after performance of the commanded TI 
burn which confirmed a trajectory that fell short of the 
target, the crew of STS-51 was prepared for the scenario that 
followed. Typically, four maneuvers, known as Midcourse 
Corrections (MC) , are planned to follow the TI burn. These 
maneuvers are intended to be much smaller than the TI burn, 
and are designed to "sweeten" the rendezvous solution. Aware 
that the trajectory following the TI burn would fall short of 
the target (having run the Future Thrust and Future Plot 
algorithms), the relatively large MC commands that followed 
came as no surprise to the crew. 

Even if the Future Thrust algorithms had been 
completely neglected, a Future Plot showing the short 
trajectory following the TI burn served to greatly enhance the 
situational awareness of the crew in a scenario of the type 
shown with this rendezvous. 

B . DEBRIEFING 

As with the flight of any aircraft, often more is learned 
after the flight than during the flight. The capability of 
playing back the recorded data through the flight software 
gives the crew the ability to view crucial moments during the 
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flight, quantify the actions they took, and critically 
evaluate those actions in terms of their results. 

Following the MC burns, as the orbiter was approaching the 
VBAR, Captain Frank Culbertson (Mission Commander) performed 
a series of small maneuvers in an apparent effort to control 
his closure rate on the target 5 . Figure 8.3 shows the 
serpentine trajectory produced by the series of maneuvers and 
the resulting 400 ft intercept of the VBAR. The 400 ft point 
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5 This conclusion was reached from viewing a video tape of the 
crew during the rendezvous. A comprehensive, face to face, debrief 
would be required to accurately assess the intentions of Captain 
Culbertson . 
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is exactly the desired VBAR crossing enroute to rendezvous. 
The question becomes; "Was the serpentine path necessary?" 

Giving Captain Culbertson the ability to replay this 
portion of the flight with access to Future Plot and Future 
Thrust algorithms provides a definitive means of answering the 
question. I believe the answer to be yes, when the issue of 
closure rate is considered. However, Captain Culbertson may be 
able to shed more light on the subject in debrief. 

Providing the astronauts the ability to replay portions of 
the flight not only enhances their ability to handle a similar 
scenario in the future, but could also help standardize the 
actions required for a given scenario. 

C . GPS ACCURACY 

Because the primary goal of the NPS software was to 
produce sawtooth plots to afford the crew a "real time" means 
of evaluating GPS data, some discussion in post-flight is 
warranted. Unfortunately, the data produced by the TANS GPS 
receiver was not part of the downlinked data stream, and is 
not available at the time of writing. Reference 2, when 
published, will have a detailed analysis of the TANS GPS data, 
although no connection with the NPS software is intended. 

As mentioned earlier, SPAS was equipped with a GPS 
receiver, and cross-linked a state vector identified as having 
a GPS origin. In an effort to somehow address GPS accuracy, a 
sawtooth comparison of the SPAS GPS state vector and the 
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orbiter INS state vector was performed during the period 
immediately after rendezvous 6 . Figures 8.4 and 8.5 show the 
sawtooth plots for these comparisons. 

It is important to note that each data point on Figures 
8.4 and 8.5 does not represent the receipt of two state 
vectors, but rather only one, either that from SPAS or from 
the orbiter. The NPS software was written such that when any 
new state vector arrives, the state vector that it is to be 
compared with is propagated with a high fidelity Cowell 
routine so as to match the time stamps. 

Initially, the appearance of the sawtooth form in the 
position difference plot (Figure 8.4) is encouraging. However, 
a comparison with the velocity difference plot (Figure 8.5), 
and an examination of the times involved indicates a behavior 
that was not predicted. The sawteeth of Figure 8.4 occur on 
the order of minutes, much faster than any possible series of 
orbiter state vector updates. Furthermore, the rises in the 
sawteeth of Figure 8.4 directly correspond to periods of 
relatively poor velocity correlation. Further investigation 
reveals that the periods of increasing position error directly 
correspond to periods when no new GPS state vectors were being 
received. The points representing GPS state vector updates are 
actually the low points of each sawtooth in Figure 8.4. The 
increasing position errors are the result of attempting to 

e The SPAS INS state vector was not used because it was no 
longer maintained after rendezvous. 
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move the GPS state vector, characterized by relatively large 
velocity error, ahead in time. 

A pure GPS state vector is derived deterministically. That 
is, at a given instant, the receiver uses the information 
available from the satellites in view to produce the state 
vector. At another instant, it is using totally different 
information. There is no memory, or put another way, the state 
vector at time t A has absolutely no bearing on the state 
vector at time t ui . Because velocity is a derivative, 
deterministic velocities carry one to two orders of magnitude 
more relative error than deterministic positions for non- 
military receivers [Ref. 2]. 

Figures 8.4 and 8.5 highlight the danger of using GPS 
derived state vectors directly from a non-military receiver. 
Non-military receivers purposely produce a certain amount of 
error so as to deny the use of GPS information for targeting. 
This is accomplished by creating timing errors in the signal 
being sent by the GPS satellites. While these errors in the 
position vector are not prohibitively large, velocity errors 
make propagation of the state vector exceedingly dangerous. 
Figure 8.4 shows that position error increases of 1000 feet 
can be achieved in a matter of minutes by propagating a GPS 
state vector. 
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Clearly, for non-military GPS receivers, some form of 
filtering is necessary if state vectors are to be used for 
propagation. The NPS software has been modified to preclude 
the possibility of propagating a GPS state vector, and will 
remain so until a fast, recursive filter becomes available. A 
more thorough analysis of SPAS and TANS GPS information with 
filtering recommendations is the proposed thesis of Lieutenant 
Carolyn Tyler and Lieutenant Steve Rehwald. This thesis is due 
for publication in June 1994. 

D. TDRSS VISIBILITY 

The TDRSS constellation consists of two satellites in 
geosynchronous orbit. It's purpose is to provide a link 
between Low Earth Orbiting (LEO) spacecraft and ground 
controllers in the United States. The Shuttle, being a LEO 
spacecraft, communicates with Mission Control at the Johnson 
Space Center via a TDRSS link. 

Ideally, when designing a geosynchronous constellation for 
global coverage, you would place three satellites in an 
equilateral triangle at the equator. The TDRSS constellation 
has this design, with the point of the missing satellite being 
over the Indian Ocean. This corresponds to a period of five to 
ten minutes of lost communications with Houston when the 
orbiter flies over the Indian Ocean. Figure 8.6 shows a 
portion of the downlinked data with gaps in the flight path. 
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These gaps correspond to the periods of lost communication 
over the Indian Ocean. 
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Figure 8.6 TDRSS Gaps 



This phenomenon of periodic lost communication strengthens 
the argument for the continued use of tools such as the NPS 
software. Should an immediate decision need to be made during 
one of these lost communicat ion periods, the flight crew would 
need access to the same types of information available to 
ground controllers. 
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IX. CONCLUSIONS 



The theory presented in the previous chapters is fairly 
straightforward, and can be found in most Orbital Mechanics or 
Orbital Dynamics texts. The algorithms contained in the NPS 
software heavily exploit the works of the great mathematicians 
on the subject of the two body problem. Since the greats have 
passed, many others have sought improvements in orbit 
prediction through accounting for perturbing accelerations. 
The numerical algorithms required to attain these more 
"accurate" solutions were simply too computationally intensive 
for inclusion in the NPS software. The justification of the 
dismissal of perturbing accelerations is the one truly 
powerful statement of this thesis. It provided the opportunity 
for graduate students at the Naval Postgraduate School to have 
a significant impact on at least one manned space flight, and 
quite possibly, all NASA rendezvous operations in the future. 

A. FLIGHT CREW REMARKS 

Ideally, direct quotation from the STS-51 FLIGHT CREW 
REPORT would be appropriate. Unfortunately, the document is 
not available at time of writing. However, some excerpts from 
the crew inputs for the document, as well as many telephone 
conversations have provided some initial feedback on the 
applicability of the NPS software. 
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For the flight of STS-51, the certified rendezvous 
software was a program called "Payload Bay" ( PLBAY ) . Unlike 
the NPS software, PLBAY is not automated, requiring manual 
inputs for most parameters. An automated version of PLBAY, 
called "Rendezvous Prox/Ops Program" (RPOP) , also flew on STS- 
51. RPOP did not offer any new functionality over PLBAY, 
however it did greatly reduce the need for user interface. 
Some of the crews comments will use RPOP and PLBAY as a point 
of reference. 

The sponsor of DTO 700-6/7 was Mission Specialist Dr. 
James Newman. The NPS software was his responsibility on 
orbit, thus he had the most favorable position for evaluating 
it's applicability. Dr. Newman has indicated that the NPS team 
"did an outstanding job, and should be really proud" of the 
NPS software. Furthermore he indicated that the NPS software 
was equally useful as a preflight training aid, and as a 
postflight debriefing tool [Ref. 8]. 

As stated in earlier chapters, the linearized equations of 
relative motion, and the Gauss problem, are both time 
constrained rendezvous solutions. The five planned burns prior 
to the visual takeover by the Mission Commander, are all time 
constrained rendezvous initiations. When asked if the NPS 
software should make these algorithms more accessible, Dr. 
Newman stated that this would make an ideal training tool, 
however, the question of validation as a control algorithm 
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would have to be addressed before consideration for flight 
certification [Ref. 8]. 

Dr. Newman was able to provide some of his inputs for the 

STS -51 FLIGHT CREW REPORT via facsimile [Ref 9] . Addressing 

the Future Thrust algorithm, he writes; 

...These programs (PLBAY, RPOP, and NPS) ran from well 
prior to TI (Terminal Initiation, the first time 
constrained rendezvous) through the entire rndz and prox 
ops. The NPS code was able to perform future burns as well 
as "what if" thruster firings and predicted that the TI 
burn would result in a short rndz case. This was born out 
and MCI though 4 all worked to correct this. 

Comparing the NPS software to PLBAY and RPOP, he states; 

. . .RPOP and the NPS plots were evaluated against the 
certified version of PLBAY and contributed to overall 
situational awareness. The NPS code had a number of 
features desirable in operational versions of RPOP, 
including the ability to select predictors more than 9 
minutes in the future. It was also able to maintain the 
no-thrust predicted trajectory and the "what-if" 
trajectory at the same time, making comparisons of desired 
thrust inputs easier to do. And NPS kept track of the 
number of "what-if" firings in the various directions and 
the net delta-v in the orbiter axes. 

Dr. Newman is also keen to point out that any algorithm is 

only as good as it's inputs; 

These tools, PLBAY, RPOP, and NPS, are only as good as the 
sensor data they receive, either directly as raw Ku radar 
data or indirectly in the filtered orbiter state vector. 

It is important to assess the quality of the sensor data, 
in this case the Ku radar data, before using the outputs 
of any of these programs. 

Finally Dr. Newman recommends that NASA 

Incorporate desirable features from the NPS code into RPOP 
to improve situational awareness during the rendezvous and 
proximity operations. 
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The Mission Commander for STS-51, Captain Frank Culbertson 
was equally impressed with the performance of the NPS 
software. He too believes the software will be valuable as a 
training aid, and is looking forward to viewing the recorded 
flight data for the rendezvous with SPAS with the NPS code 
[Ref. 10] . 

Summarizing the impact of the NPS software, Captain 
Culbertson stated [Ref. 10]; 

The product was outstanding, and gave insight not 
previously available. It was one more tool to help 
maintain the "big picture", and anything that increases 
situational awareness is valuable. A program (such as the 
NPS software) that processes data "real time" 
significantly enhances the crew's ability. 



B. FOLLOW ON RESEARCH 

Based on the commentary of the crew of STS-51, NASA is 
quite serious about the merger of the NPS software and RPOP. 
If any of the theory of the NPS software is to be validated by 
NASA, a detailed comparison of the theoretical differences 
between the NPS software and RPOP will be required. 

1. Lambert Targeting 

Although neglecting the effect of perturbing 
accelerations on a rendezvous solution produces very little 
error in the prediction of relative motion, error is still 
generated. Lambert targeting is designed to compensate for 
this error. The method requires iterations of a numerical high 
fidelity propagator and is therefor extremely computationally 
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intensive. The solution to the Gauss problem addressed in 
Chapter VII began with using the f and g functions to 
determine the target's position vector at the desired time of 
rendezvous, while Lambert targeting uses the high fidelity- 
propagator to get this vector. Both methods then use the two 
body time constrained rendezvous solution to obtain the 
desired thrust. However, since the Lambert routine does not 
account for perturbing accelerations in the rendezvous 
solution, the calculated thrust will be somewhat in error. The 
Lambert routine then propagates (high fidelity) the chaser 
ahead with the input velocity changes and measures the error 
at the rendezvous end of the problem. The inverse of this 
error vector is then used as an offset aim point for another 
two body solution, and the chaser is again propagated ahead. 
The process is iterated until the "miss distance" is 
acceptably small [Ref. 7]. 

Since Lambert targeting is quite time consuming, the 
algorithm must be initiated well prior to the planned thrust. 
As stated in previous chapters, the first time constrained 
rendezvous solution occurs at TI (the last apogee before 
passing the target, see Figure 8.2) . Thus for the period prior 
to TI, the passage of time corresponds to a decrease in 
distance to the target. Decreasing the distance to the target 
continually improves the relative error between the target and 
chaser state vectors via the KU band radar. It was this 
passage of time, and corresponding closure of the target, that 
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allowed for the NPS software to produce a better solution at 
TI than the Lambert targeting solution that was produced with 
inputs from a half an orbit prior to TI . 

To completely address which method is best for 
computing the TI burn, a detailed analysis of the errors 
produced by the pure two body solution (like the methods of 
Chapter VII), and the errors produced by older inputs for 
Lambert targeting, is required. In performing this analysis, 
a further consideration is the ability of the crew to execute 
an exact rendezvous maneuver. Because thruster inputs have a 
finite number of digits available (typically down to tenths of 
a foot per second) , the extra computation performed by the 
Lambert routine may well refine the solution beyond the point 
of input . 

2 . Inclusion of a Lambert Algorithm 

Recognizing the reluctance to abandon an algorithm 
that has worked for many years, the NPS software could 
certainly be modified to include the Lambert algorithm. This 
inclusion could also serve to help in comparison of the two 
methods. At the very least, a significant speed up of the 
Lambert algorithm may be realized by using the output of the 
pure two body problem as a starting value. 

3 . Time Constrained Rendezvous Accessibility 

The NPS software was not written with any particular 
standard maneuvers in mind. Specifically, when a time 
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constrained rendezvous solution is desired, the user must 
input when it is to start and stop. However the beginning and 
ending of all five of the time constrained algorithms can be 
calculated. The time at TI is that of the last apogee prior to 
passing the target, which is available via the f and g 
functions. The rendezvous is to be completed within 320”, 
which can be translated into a time via Kepler's equation, 
giving the start and stop time for the TI burn. The MC burns 
occur at fixed times relative to the TI burn, and can be 
assumed to complete a rendezvous at the same time as the TI 
burn. The NPS software should be modified to produce the time 
and thrusts required for the TI burn, as well as the MC burns. 

4. Drag Accelerations 

The accelerations caused by aerodynamic drag are a 
function of velocity and the size and shape of a vehicle. The 
argument for excluding drag accelerations when using the f and 
g functions, stems more from the insignif icance of drag 
effects at the altitude of STS-51, than from the similarity of 
velocity vectors. If proximity operations are planned for a 
very low orbit, then drag accelerations must somehow be 
accounted for. With a constant atmosphere (Standard Day for 
instance) assumption, it is possible to estimate the altitude 
loss per unit time as a function of altitude, thus providing 
a fast analytic method for dealing with drag accelerations. 
The Future Plot and Future Thrust algorithms should be 
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flexible enough to operate in a very low altitude, high drag 
orbit . 

5. Vernier Effect 

Vernier effect is a term used to describe the apparent 
increase in energy of the shuttle's orbit over time. The cause 
is believed to be residual Av from attitude control jets that 
are not perfect couples. After passing through the VBAR, just 
prior to rendezvous, the Future Plot algorithm showed that the 
orbiter would again reach the VBAR 110 feet in front of the 
target (Figure 9.1) . The orbiter did not actually reach the 
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Figure 9.1 VBAR Prediction 



VBAR until about 30 feet in front of the target [Ref. 10] . 



This 90 foot difference is quite significant when considering 
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the range to the target. During this period, the orbiter was 
maintaining a constant LVLH attitude, that is to say it was 
pitching with respect to inertial space. The attitude control 
thrusts required to hold this attitude are believed to be the 
cause of the excess energy. Currently, none of the software 
packages have a means of addressing this problem. If a means 
of quantifying the residual Av becomes available, it should be 
incorporated into the Future Plot algorithm. 

6 . Target Attitude 

Although the NPS software never addressed the target's 
attitude, target attitude information was available. During 
the rendezvous, Dr. Newman was observed using his right hand 
in a three axis orientation, trying to discern the target's 
attitude from pitch/yaw/roll angles provided by another source 
[Ref. 11], Since the target quaternion is available, a 
graphical representation of target attitude with respect to 
LVLH or orbiter fixed space is possible. Captain Culbertson 
believes these pictures would be most helpful, as the mental 
gymnastics involved with deciphering the pitch/yaw/roll angles 
would no longer be necessary [Ref. 10]. 

C. SUMMARY 

While the NPS software performed well, there is indeed 
room for improvement . Since the algorithms are not yet 
certified, access to the software for the purposes of making 
improvements is not difficult. Once the algorithms are 
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incorporated into a certified piece of software, they will 
become somewhat less accessible, and any changes will have to 
go through the validation process. Several changes have been 
made since the flight of STS-51, such as the inclusion of 
closure rate, out-of-plane rate, and improved graphics. 

Participation on the NPS team necessitates direct contact 
with the next crew planning to use the NPS software, 
responding to their needs, and making improvements that will 
enhance the value of our product in the eyes of the user. It 
also provides an ideal opportunity for an experience tour in 
the Astronaut Office, gaining first hand exposure to the needs 
of a crew on orbit. 

If the recommendations of the STS-51 crew are followed, 
some portions of the NPS software will live on in another 
program, and have an influence on manned space flight for 
years to come. However, the amount of influence rests on the 
continued relationship of the Naval Postgraduate School with 
the Astronaut Office at Johnson Space Center. It is my sincere 
hope that other students will follow our path, and continue to 
improve the NPS software, making it the invaluable all 
encompassing rendezvous/prox ops software that NASA seeks. 
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